Getting Started As A Product Manager

I remember the day when I got my first internship at Microsoft as a program manager. It was such a new concept to me at the time - months before my interview took place I was hastily doing my research, trying to figure out what does a PM do. One of my first explorations in that domain was through a post from Steven Sinofsky - PM at Microsoft. One part stood out:

[…] it is PMs that can bring together a team and rally them around a new idea and bring it to market […]

Yes, that is exactly what I wanted to do! I like to think that at the time I was somewhat confident in my code-writing abilities, but I also wanted to be much closer to my users. I wanted to figure out a way in which I can help define the shape of a product before it becomes a set of work items for the engineering team. That statement was the guideline I had when I stepped into the warm lobby of Building 36 on the Redmond campus for my program manager intern interview.

Seven years later, I asked myself the question - what is something that I wish I knew when I was first starting as a program manager? This post is a distilled version of the answer.

Realize you are part of a team #

When new grads start their PM jobs, there is this false assumption that “I am in charge of everything related to a feature.” After all, you have the “manager” in the title, so you should be managing something, no? No. As a product/program manager, your role is to aggregate the best ideas, analyze them, and build a plan to ship a product (or a segment of one) that solves specific customer problems. Your goal is to partner with other PMs, your engineers and customers to ideate - you don’t tell people what to do, but rather work with them to deliver an experience.

Talk to customers #

Do not, I repeat - do not work in isolation. This is the most cardinal sin you can commit as a product/program manager. The reality is that all the ideas that you come up with in a room by yourself are likely to fall apart the first time you talk to a customer (this applies to business plans too). When you are assigned a product or a feature, your first goal should be to get some of your thoughts in front of real customers and start building an understanding of how they would use your product. It’s not enough for you to be excited about your product - you need to make sure that you customers are as well.

It’s OK to fail #

Most of the time, the original assumptions you will make about the product will fail. I recall at one point the design team and I worked on some mock-ups for a feature in Outlook that we re-did five or six times, purely because we were very closely engaged with customers and we found issues that we haven’t seen before we actually talked to people using our tooling day in and day out.

As a product/program manager, your goal is to optimize failure for learning - what can you do to learn and fail fast, before shipping something that is actually impactful? There are many answers to this question, including user studies, A/B testing and experimentation, deep data analysis and others. Figure out what works best for your team and project, and start failing. The key is not to be discouraged by it and only produce failing outcomes.

Have conviction #

As a PM, you will be subjected to the thoughts and opinions of many different parties - peers, customers, engineers, bystanders. If you have no conviction, all you will do is spin in circles trying to refine an idea. Do your due diligence, analyze the market, get a plan out and start shipping. You will never reach perfection when it comes to product design and development, but shipped is better than perfect. Shipping allows you to, once again, test your assumptions and learn. Having conviction that your ideas and proposals are good to go out the door will be critical to your success.

Learn to define a minimum viable product #

When you start working on a product, new feature and improvement ideas will likely pop up relatively frequently. The problem with that is that you have limited time to go to market before either you competitor does, or before you can learn. This blog post by Henrik Kniberg describes pretty well what an MVP is and it isn’t. Stop trying to ship something that has everything, and instead focus on shipping something that can provide value to your users (even if it’s not 100% of it).

Be grounded in data #

One of the best skills you can have as a PM is being able to look and analyze data that is coming for your product. Data eliminates guesswork. Once you start looking at numbers, you have the power to drive decisions in the direction that is the most meaningful for your product. And of course - question numbers. Not all data is good data. A heatmap showing you distribution of eye gaze/clicks on a certain area does not mean that it indicates the true focus of your customers - maybe your customers are just too concentrated on that particular area because they can’t find the true piece of value they are after. Ask a lot of why questions when doing your analysis.

Conclusion #

While there is no single recipe for what defines a PM, I hope to help document more of my learnings in a way that is useful for the broader PM community, that would help newcomers and seasoned veterans grow. Stay tuned for more!